home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000102_owner-urn-ietf _Thu Nov 7 13:04:14 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00691 for urn-ietf-out; Thu, 7 Nov 1996 13:04:14 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00686 for <urn-ietf@services.bunyip.com>; Thu, 7 Nov 1996 13:04:12 -0500
  3. Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23567  (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:04:10 -0500
  5. Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.8.2/8.7.3) with SMTP id JAA16220; Thu, 7 Nov 1996 09:47:38 -0800 (PST)
  6. Date: Thu, 7 Nov 1996 09:47:38 -0800 (PST)
  7. From: "Gregory J. Woodhouse" <gjw@wnetc.com>
  8. To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  9. Cc: Keith Moore <moore@cs.utk.edu>, urn-ietf@bunyip.com
  10. Subject: Re: Names and Locations (was [URN] some comments) 
  11. In-Reply-To: <199611071646.KAA07336@ncsa.uiuc.edu>
  12. Message-Id: <Pine.SGI.3.95.961107092024.12299A-100000@shellx.best.com>
  13. X-Url: http://www.wnetc.com/
  14. Mime-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. It still seems to me that the issues is one of mechanics. It seems fine to
  22. specify that the namespaces http:, ftp:, gopher:, etc. are reserved for
  23. URLs so that a client knows a priori that when it sees
  24.  
  25. http://foo.bar.com/
  26.  
  27. it knows it only need  connect to foo.bar.com and retrieve the resource.
  28. But without doing such a check, the client would have to assume the above
  29. URI *could* be a URN and attempt to resolve it. In a sense, this isn't a
  30. huge restriction because the client needs to know how to retrieve resources
  31. specified by a URL, anyway, so it must know which namespaces are possible.
  32.  
  33. A separate issue is whether the above URI could represent different
  34. resources when interpereted as a URL or a URN. This is, of course, only
  35. possible if the same namespace can have multiple semantics, and my
  36. understanding is that this is not the case, but to be honest, I don't see
  37. where this is spelled out.
  38.  
  39. Finally, a possible design is to have the above URI be both a URL and a
  40. URN. By this, I mean that whatever service is responsible for resolving URNs
  41. will recognize and deal appropriately with namespaces such as http:. But it
  42. is obviously desirable not to have to go through the process of resolving a
  43. URN just to get back a URL that is identical to the original URN. (In the
  44. case of NAPTR we could have an N2R resolution, but then scalability issues
  45. come to mind.)
  46.  
  47. Now, if I'm missing something fundamental, by all means tell me, but this
  48. seems like a real issue to me. It seems that omitting the urn: prefix would
  49. not break anything (unless of course a URI is allowed to have different
  50. referents depending upon whether or not it is a URN), but it may still be
  51. useful, just as it may be useful to have a url: prefix for URIs that are in
  52. fact URLs.
  53.  
  54. ---
  55. Gregory Woodhouse     gjw@wnetc.com
  56. home page:            http://www.wnetc.com/home.html
  57. resource page:        http://www.wnetc.com/resource/
  58.